It s often said that KDE and GNOME are too bloated, too complex, too slow, or whatever. I won t deny that these critics are often justified, and some parts of the code are badly designed. But there can also be reasons behind this bloat: they are called features. When you want to mount an encrypted USB disk, you can write your own script and even write your own udev rules so that it can be mounted with autofs. It looks fun to find a way to use software that has been obsolete and useless for 10 years, in a way that requires administrator rights just to add a new model of USB disk to your system, and puts the private key in a place that is readable for anyone stealing the hardware. But while it will turn out as an interesting read for those willing to understand how the device mapper and cryptsetup work, I think it s a bit abusive to present it as a correct implementation of an encrypted disk mounting setup. Discover gnome-disk-utility In etch, GNOME shipped with pmount, a nice utility, still included in Debian, that allows to mount your keys, encrypted or not. In lenny, it shipped with HAL, and allowed to store LUKS passphrases securely in the GNOME keyring. Whenever you plug a LUKS-encrypted disk on a lenny system running GNOME, it is immediately made accessible, and that s all. In squeeze, things go much farther thanks to udisks (the backend) and gnome-disk-utility (the frontend). Roland rightly pointed out that the g-d-u documentation is nonexistent - it consists only in a screenshot, which is outdated. Nevertheless, you will find it practical if you want to encrypt a USB drive, since you can format it, partition it, create encrypted volumes and the filesystems on them, in a few clicks and without root permissions. If you use nautilus, it will also mount them automatically using the same backend when you plug them. I don t know for you, but I think it is worth a few CPU cycles of my 3GHz processor and a few dozen megabytes of my 500GB drive.

You have a computer. You're afraid of it being stolen by baddies or raided by the police, so you've encrypted its hard disk with LUKS. You also want to carry around some of your crypto keys (SSH and/or GPG), or any kind of sensitive data, on an USB key, so you can restore a normal activity in case the computer gets stolen or becomes untrustworthy. You like things that Just Work, including automounting with autofs (no GUI popups, no need to manually unmount and so on). But of course, you can't very well just mount the drive and store your keys on it in the clear. Well, actually you can (I did it for way too long), but let's assume you want to do without. Because USB keys get stolen or lost, too. autofs just handles the mounting of the drives, not their unlocking, and there's no hook in there specifically for LUKS. There is, however, a more generic way of running arbitrary commands on mounting: the program maps. It's all described in the documentation, so I'll just paste the relevant parts of my /etc/auto.removable, with a few comments. Remember to make it executable and reference it in /etc/auto.master.

 #! /bin/sh
 volume=$1
 autoluks ()  
   dev=/dev/$1
   cryptname=$ 1 _crypt
   cryptdev=/dev/mapper/$cryptname
   keyfile=/etc/private/$cryptname.key
   options=$2
   [ ! -e $dev ] && exit 0
   if [ -b $cryptdev ] && ! cryptsetup status $cryptname   grep -q device:.*$dev ; then
       cryptsetup remove $cryptname   logger
   fi
   cryptsetup --key-file $keyfile luksOpen $dev $cryptname   logger
   [ -b $cryptdev ] && echo $options :$cryptdev   true
  
 case "$volume" in
   # LUKS-encrypted volumes
   lacie-keys)
       autoluks lacie-keys -fstype=ext4,ro,noatime,nodev,noexec,nosuid
       ;;
   lacie-keys-rw)
       autoluks lacie-keys -fstype=ext4
       ;;
   lacie-backups)
       autoluks lacie-backups -fstype=ext4
       ;;
   # Non-encrypted volumes
   cd)
       echo -fstype=iso9660,ro,nodev,nosuid            :/dev/cdrom
       ;;
   floppy)
       echo -fstype=auto,sync,nodev,nosuid             :/dev/fd0
       ;;
 esac

The astute reader will have noticed that the keys volume is mounted either read-only or read-write with the same mechanism. This volume contains SSH keys that I use quite regularly, that filesystem is going to be mounted and unmounted very often. USB keys, and flash memory in general, don't really like repeated writes. Fortunately, the SSH keys are mostly read, and very rarely written to, so I can afford to mount the partition read-only and save the write cycles for when I generate new keys (the mere action of mounting a partition read-write changes it, even if the files in it are never modified). The backups volume is mostly accessed in write mode, and much less frequently anyway, so there's no need for a distinction there. This supposes that the partitions on the USB key appear as /dev/lacie-keys and /dev/lacie-backups. Due to the dynamic naming of devices, you may like to use rules similar to the following in /etc/udev/rules.d/local.

 KERNEL=="sd[a-z]1", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-keys"
 KERNEL=="sd[a-z]2", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-backups"

You'll also need to initialize LUKS on the partitions, save the key, make the filesystems, and so on. If you're still with me, you probably know what I'm talking about, then I don't need to explain about that. This setup works for me, but there's no guarantee and so on. Based on a tutorial found on the Debian Administration website (great resource, by the way). Update: I'm told a large part of the script could be replaced with pmount. If you like short scripts, you may want to investigate that too. Update 2: Josselin points out a different solution using Gnome, udisks, gnome-disk-utility and Nautilus. It's worth checking out, for those who like to run all that and click around. I can't test it right now (Gnome/Nautilus currently refuses to mount any USB key, for some presumably transitional reason), but I have no reason to believe it's inherently broken. I just don't like having to do anything when I plug my key or before I unplug it, and I'm not always running a graphical session with a desktop.

A new paper of ours was just published. If you re curious about all that Semantic Web and Linked Data hype and how it would impact forges and other software development tools, and the link with Open Source development platforms, then, read this :

Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice
(DOI: 10.4018/jossp.2010040103)
Authors: Olivier Berger (Institut Telecom, France); Valentin Vlasceanu (Institut Telecom, France); Christian Bac (Institut Telecom, France); Quang Vu Dang (Institut Telecom, France); St phane Lauriere (Mandriva, France)
in International Journal of Open Source Software & Processes (IJOSSP) Volume: 2, Issue: 2 (2010), Pages: 29-40 pp.

Here s the abstract:

Several public repositories and archives of facts about libre software projects, maintained either by open source communities or by research communities, have been flourishing over the Web in recent years. These have enabled new analysis and support for new quality assurance tasks.
This paper presents some complementary existing tools, projects and models proposed both by OSS actors or research initiatives that are likely to lead to useful future developments in terms of study of the FLOSS phenomenon, and also to the very practitioners in the FLOSS development projects.
A goal of the research conducted within the HELIOS project is to address bugs traceability issues. In this regard, the authors investigate the potential of using Semantic Web technologies in navigating between many different bugtracker systems scattered all over the open source ecosystem.
By using Semantic Web techniques, it is possible to interconnect the databases containing data about open-source software projects development, which enables OSS partakers to identify resources, annotate them, and further interlink those using dedicated properties and collectively designing a distributed semantic graph.

Keywords : RDF, forge, archive, bug, semantic, semantic Web, ontology, database, repository of repositories,
interoperability, bugtracker, OSLC-CM, Debian. The journal is published as closed content on paid access, but you may ask us, should you need to read a draft version. This is an extended version of an earlier position paper presented at WOPDASD 2009. This work was conducted in the frame of the System@tic Paris-Region cluster (http://www.systematic-paris-region.org/), with funding of the Paris Region council.

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years¹. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

After skipping 3 entire releases, and 18 months later, here we are, finally: GDM 2.30 is entering unstable. How can you be so late? For those who haven t followed and just wondered why Debian is so late this is lame this sucks Ubuntu is better because they have the latest version and Fedora is even better because they even have versions that don t work at all, here is the short story: the GDM rewrite wasn t really usable until 2.28 (which is the version with which Ubuntu started to ship it, incidentally). Add to that the time to make a transition plan and to integrate it properly, and that makes actually only 6 months. Big thanks go to Luca Bruno (Lethalman) who did most of the job. A quick look at the changelog will give you an idea of the amount of work involved to bring it to our quality standards. GDM 2.20 and 2.30 Since the rewrite has absolutely zero compatibility with previous versions, it will not be upgraded in place. Therefore, while newly installed systems will get GDM 2.30 by default for squeeze, those upgrading from lenny will keep GDM 2.20. The 2.20 version will be dropped after the squeeze release. If you want to upgrade your GDM, simply run apt-get install gdm3. It should work for simple setups, and there s a hack that makes upgrades work even when logged on X. Everyone who has needs for advanced features (such as LTSP people) should make sure GDM 2.30 suits their needs during the squeeze cycle, since the old version will not be here anymore after. GDM packages need your help Finally, here is a call for translations. Anyone can help: just grab the gdm3 sources, get the .pot files and translate them to your language. Beware, there is one file in debian/po for the desktop files and one in debian/po-up for the patches. (I will try to merge them in a later version.) Then submit your translations as bug reports.

It takes a lot to prepare for a big trip if you want to really enjoy it. This time, we re going to Japan, and we bought some stuff to stay connected there. First, there s the new camera: that s a Sony 230. We haven t made a photo trip to see all its capabilities yet, but it looks like an excellent toy so far. You ll see probably more photos on this blog in the future. And there s the new laptop: a Packard-Bell Dot-M/A. Theoretically it s called a netbook, but in practice it has everything a real laptop has. The reason I chose this model is that it features Radeon (X1270) graphics and a 64-bit processor, all in a 11,6" laptop which is one of the cheapest of all. Lots of power in one kilogram for a low price, although the drawback is more cells in the battery. Getting the Dot-M/A to work under Debian I first tried to install lenny on it, and while it worked nicely there are several problems with hardware support.

1. The CPU runs extremely slow; you would think it is an Atom. It takes no less than one minute to boot a minimal installation. This is a very strange issue.
2. Wi-Fi doesn t work, even after installing the firmware.
3. 2D works out of the box, but 3D doesn t: the kernel doesn t recognize the PCI ID.
4. Frequency scaling doesn t work, it always runs at full speed which eats battery at an impressive pace.

Upgrading to squeeze solved the first three issues in a blink. The CPU is now as fast as you can expect from an Athlon 64 @1,2 GHz, there s wifi and 3D. OTOH I was hit by a GStreamer bug when the useless snd_pcsp module was loaded why isn t this thing blacklisted by default? ACPI nightmare CPU frequency scaling is another story. I discovered that the BIOS for such Athlon L110 computers does not expose P-states in the ACPI DSDT table. Which means Linux cannot tell at which frequencies it is supposed to work. However, thanks to the awesome work from a guy named Krists Krilovs and the awesome tutorial from the Gentoo wiki I was able to:

• rip the DSDT table from the CPU that s the easy part;
• disassemble it using Intel tools still easy;
• debug the table, which is written in an arcane language no one understands, and using references to a tutorial that was probably excellent until it disappeared from the intarwebs;
• integrate the P-states for the Athlon L110, basing again on the work of Krists Krilovs who wrote the corresponding ASL code;
• build a custom kernel using it that s the easy, but long part, that s done on a faster computer.

After a reboot, I immediately noticed the fan slowing down. Under GNOME, the CPU was no less than 10 C cooler and the CPU frequency applet started to work. <hrule> The Debian kernel maintainers deliberately chose not to provide support for loading a DSDT table from the initrd. There are very good reasons for this, and anyway it shouldn t be necessary to hack something as awful as that to have power saving support. The question remains: how do we deal with this madness? There needs to be some kind of support out-of-the-box for the Athlon L110, which is otherwise a very nice beast. Could the powernow-k8 module set hard-coded defaults when it detects this CPU model? It would be better than the current situation. Other pieces of the toy Otherwise this laptop is very good hardware. Among other things, I enjoyed:

• the keyboard which is very comfortable for this size;
• the awesome screen, quite small, yet 1366 768 and very bright and sharp;
• the quite fast SATA disk (~60 MB/s);
• the card reader, which makes a useful replacement for a CD drive;
• the webcam that worked out of the box;
• power management that works just as expected too.

There is one minor annoyance: the integrated RealTek Ethernet card is only 100 Mbits/s. With all this performance otherwise, you would have expected Gigabit, but well, not everyone has GigE at home yet.

If you want to help the Debian/GNOME team, now is the time. For two days, we are going to triage as many bugs as possible. I have prepared a little wiki page that explains what you need to help and how to start. Of course, the team members will remain available on IRC to give advice.

Do you like Debian? Do you like GNOME? Do you want to help Debian and GNOME?

If you have answered yes to all those questions, join this weekend on #debian-gnome on irc.debian.org / irc.oftc.net and participate in the Debian/GNOME bug session! More information at Joss s blog.

RCBW - #22 With a mini-rush in the week-end, I'm now back on track to the weekly schedule of RCBW; here are this week's squashes:

• bug #565274 - tex4ht - test and close bug fixed by recent binNMU
• bug #553553 - phpsysinfo - fix dir-or-file-in-var-www, based on a patch by Mats Erik Andersson
• bug #553496 - doc-central - fix dir-or-file-in-var-www, sponsor NMU by Mats Erik Andersson
• bug #559821 - libtunepimp - fix libltdl CVE (bonus fix bug #476378), patches by Yavor Doganov
• bug #568982 - sqldeveloper-package - port from dos2unix to fromdos, patch by Michael Musenbrock
• bug #534721 - libhpricot-ruby1.8 - error in printing tags to stdout (fixed upstream in a version already in Debian)
• bug #564680 - gnugk - rebuild against firebird 2.1, as requested by Damyan Ivanov (important bug blocking RC bug #549062)

About this week highlights:

• In his latest RC-bug statistics, Tolimar has pointed to the RCBW description as inspiring. That's good, I hope more and more people can find it inspiring (in fact, that's why I wrote it). A handful of people doing RCBW is pointless, unless as a side-effect we manage to change the culture of our project in order to be more collaborative on how we reach a release.
• I've been amazed by how many RC bugs are "stuck" just because no one took care of establishing communication among the appropriate people. That of course happens when the maintainer of the bug has been unresponsive, but some investigations of the bug is usually enough to make the appropriate people (upstream, porters, related package maintainers, ...) aware of it ... and then the bug will "mature" all alone.
• Josselin has announced the Debian/GNOME bug weekend for the next weekend (27-28/02/2010): an initiative to collaboratively triage GNOME-related bugs in Debian. For large-enough packages (and GNOME fits that definition for quite some different notions of "large"), such efforts are as badly needed as RC squashing: if you liked RCBW, you can't miss the GNOME bug weekend

Do you like Debian? Do you like GNOME? Are you free on February 27-28? If so, please reserve your week-end, because you are going to help us do a massive cleanup in the insane amount of bugs submitted against GNOME packages. You don t need any special skills. Just join on #debian-gnome and we ll provide all the guidance you need. Ultimately, the goal is to have, at the end of that week-end, all bugs against GNOME packages in one of those states:

• closed
• forwarded upstream
• having a fix ready to upload
• waiting for more information from the submitter

After this, maybe the BTS can become useful again for the GNOME team.

A picture is worth a thousand words: A slightly longer story follows, resuming from the previous episode, where Gtk seemed to be working. Making sure Gtk actually works Since the udebs are quite fat already, I decided to put the contents of the gtk2.0-examples package into a new revision of the new libgtk-x11-udeb package. gtk-demo was running fine (if one forgets that this demo application is really easier to deal with if one uses a window manager), although image handling was broken. Julien and I spent quite some time double-checking that the libpixbufloader-png.so plugin was present; that both previous DirectFB-based udeb and new x11-based udeb were very similar; that configuration was generated properly; we went so far as to include strace in the netboot image, and to check the configuration file was open() d, but the plugin was never to be even looked for. All this resulting in a Unrecognized file format message every time. Josselin, our Messiah, enlightened us: although Gtk was previously using some configuration files to determine which pixbufloader plugin to use, it still continues to access those files but relies on a MIME database in the end. Installing the host s /usr/share/mime/mime.cache database did the trick (we have a proper fix pending), and all of a sudden, we got image support (which is needed for the logo_installer.png displayed on top of every screen, as well as for some icons during the installation, like the final one). Tweaking d-i itself Julien took care of rootskel-gtk. It was mostly about:

• Dropping some DirectFB start-up scripts.
• Dropping a related configuration file.
• Adding a start-up script doing trivial things:

  Xorg -retro -noreset &
  export DISPLAY=:0
  

Another easy step was cdebconf. Mostly: search and destroy on the few bits using DirectFB. An interesting issue we had was that even though a proper cursor theme was installed and made the default, we only had a black cross as X pointer. That s where we learnt it s needed to manually set a cursor for the root window, which can be done this way:

GdkCursor *cursor = gdk_cursor_new(GDK_LEFT_PTR);
gdk_window_set_cursor(gdk_get_default_root_window(), cursor);
gdk_cursor_unref(cursor);

Tweaking gtk2-engines was trivial, just a matter of building against the x11 flavour of Gtk instead of the directfb one. Some substitutions in debian/control and debian/rules, and that was done. Julien also took care of tweaking console-setup so that keyboard-configuration s and console-setup-udeb s postinst scripts call setxkbmap when $DISPLAY is set. Meaning we were able to replace kbd-chooser with console-setup-udeb, leading to a correct setting within X right after having selected the layout! Reverting d-i s r61645 (which disabled Gtk-based d-i images) was trivial (although while looking back, it was probably unnecessary), and after having messed around with the packages lists (there s a lot of local udebs at this point), especially to add some fonts, we managed to get an image which seems to work fine (at least in my VirtualBox environment). I tried Chinese, Japanese, Arabic, and French installations, and all of them seem to work fine (installed systems were bootable after an installation in the selected language) while issues were limited to some rendering or translation glitches, which didn t seem critical at all. Next steps Since there were some iterations, and since the trial-and-error approach was chosen, the first goal is to generate clean patches against all modified packages, and make sure a single walk through all packages in a clean chroot is sufficient to generate a working d-i image again. Once that done, which should probably considered (at least, I hope!) quite a good base already, the idea is to look into the various udebs to see whether there are some parts that could be disabled (maybe introducing a trimmed-down flavour especially for the udeb in some non-flavoured-yet libraries), so as to reduce the size of the resulting image. In the meanwhile, one can fetch the current hand-built netboot image by browsing http://people.debian.org/~kibi/di-x11/. It s only available for amd64, and weights 23MB. There s a sha256sum as well as a detached GPG signature in the same directory.

Producing udebs How to patch That s actually quite trivial. Most packages from Josselin s 1st and 2nd lists are libraries, and generating udebs for libraries is easy. Basically it boils down to declaring a new binary package:

• Duplicate the libfooN entry in debian/control.
• Add the -udeb suffix to the Package line.
• Add a Package-Type: udeb line.
• Make sure Section is debian-installer.
• (Maybe) make sure Priority is only optional.

Now, populating it might depend on the considered source package, but thankfully, pkg-x11 packages are quite sane, using debhelper s dh_install. So duplicating debian/libfooN.install into debian/libfooN-udeb.install is usually sufficient. It s a bit trickier when dh_movefiles is used, but calling install and cp -r after the dh_movefiles call should be sufficient. Next step, tweak shlibs for libfooN. Without that step, a libbarM package built against libfooN would get libfooN in Depends, which is not appropriate. The idea is to get libfooN-udeb instead. Trivial: add --add-udeb=libfooN-udeb to the dh_makeshlibs call. Possible issues at that step:

• debian/shlibs or debian/libfooN.shlibs is used instead of dh_makeshlibs. Trivial fix: feed its contents to dh_makeshlibs through its -V argument, and delete that file. Caveat: when it comes to applying a patch removing that file, make sure it s actually removed, and not just empty. I m going to file a bug about that, the default behaviour with empty files seems a bit buggy.
• Several libraries are shipped: one can t pass several --add-udeb arguments. Solution: use several dh_makeshlibs -p$pkg -V$depends --add-udeb=$pkg-udeb call. (I thought it was needed for libx11 but I can t read, actually: libxcb1 libx11-xcb1.)

Various checks to perform:

• Make sure debian/libfooN/DEBIAN/shlibs is correct: it should have a udeb line. Example:

  libfoo N libfooN (>= some-version)
  udeb: libfoo N libfooN (>= some-version)
  

• Make sure the generated udebs have no non-udeb packages mentioned in Depends. Since I m still at the proof-of-concept stage, I ve iterated when I encountered such additional packages, without checking what was actually needed. The idea is to get rid of extra stuff once the final needs figured out. Of course, one has to track down the dependencies to get the packages incrementally built and installed (for the updated shlibs files).

Results (These files might be moved around during the following steps, but this post shall be kept up-to-date and point to them at all time.) Legend:

• Red box: package needing a patch.
• Green box: package already udeb-aware.
• Label with [n]: package patched at step N.
• Label with a *: warning when patching, shlibs file to be removed.

Graphs are scaled down to 75%, click for full size. Step 1:

• Patches: udebs-1/diffs/
• Udebs: udebs-1/udebs/
• Notes: as explained above, libx11-xcb1 is probably not needed.
• Dependency graph:
  

Step 2:

• Patches: udebs-2/diffs/
• Udebs: udebs-2/udebs/
• Dependency graph:
  

Adding udebs to a d-i image Basic d-i image General guidelines (see d-i documentation for detailed installation, needed packages, etc.):

svn co svn://svn.debian.org/svn/d-i/trunk/ debian-installer-trunk
cd debian-installer-trunk/installer/build
make build_netboot

If that breaks (e.g. due to missing packages), make sure there s a similar entry in sources.list.udeb:

deb http://yourmirror/debian squeeze main/debian-installer

If everything goes well, the generated image should be available as dest/netboot/mini.iso, and tmp/netboot/udeb.list should contain the list of embedded udebs. To give it a try:

qemu-system-x86_64 -cdrom dest/netboot/mini.iso

Actually adding udebs Drop all additional udebs under localudebs/. Needed Packages and Packages.gz should be generated on the fly (but beware, secure apt is then disabled, even for non-local udebs). Now, tell d-i we want some more packages. If all of them are wanted, one can do that:

for i in localudebs/*.udeb; do \
  dpkg-deb --showformat='$ Package \n' -W $i; \
done > pkg-lists/local

(Update: Thanks to Guillem for pointing out a better and cleaner way than dpkg --info $i grep Package: awk ' print $2 ') Generate a new image (note the rebuild part of the target):

make rebuild_netboot

Make sure they got added by looking in tmp/netboot/udeb.list and profit! What s next Future steps include:

• Making sure those udebs are actually usable.
• Reworking Pango/Cairo/Gtk udebs.
• Taking a look into X itself.

Stay tuned.

(Disclaimer: this post is not about G.I.) Graphical installer Josselin posted his thoughts about g-i, and given at least the first parts sound doable, I m tempted to have a look at dealing with the needed udebs. Never touched anything like this before, but oh well, one learns every day. Time to learn a bit more about X11 as well. It looks like generating a new mini.iso (using d-i s trunk) wasn t that difficult, so hopefully once I m done with a few udebs, it should be possible to add them to this image and make sure those are usable, at least when loaded manually. Once that finished, gluing everything together is probably going to be another story, but hopefully that won t be impossible. Unrelated stories

• Thanks to DSA (especially weasel), kfreebsd-* now have DSA-admin d experimental buildds. Aur lien took care of setting them up; they managed to go through all experimental packages, and bugs were filed accordingly. Some were just marked as failed, usually with Needs porting. , especially when there were no regressions with respect to what was previously built on those architectures (as a reminder: out-of-date means serious, uncompiled means important).
• On a related note, this buildd.d.o form makes it possible to browse the build logs for various suites. See the dda@ announce for details.
• It looks like I m going to stop dealing with Java at all: #557230. Thanks to Gabriele Giacone for taking care!
• It also looks like I m done with Python packages as well.
• A new module-assistant package got uploaded, which should fix issues with newer kernel versions (ya can haz detailz). I m wondering whether backporting it through backports.org from time to time would be of some help to anyone? It is (or should be) directly installable in a lenny environment, but maybe people would like it to be directly available once the lenny-backports repository enabled? Mail/wishlist bug welcome if you want it.
• If you received some signatures from me lately no, I wasn t pretending I met you at LCA or whatever, but that was from C ceres (Hi Penny! ;)). Key rollover being thought of.

The current state of g-i, the graphical version of the Debian installer is very concerning. Currently, the GTK+ version in squeeze (2.18 and soon 2.20) has very serious bugs in the DirectFB backend, which make it unusable for g-i. Because of that, the first alpha version of d-i will ship without graphical installer support. Unless someone steps up and does something, this will be the end of the graphical installer. Among other things, it means the end of support for several languages: Indic scripts, Thai, Amharic, and all RTL languages. Option 1: fix GTK+ DirectFB support Until now, we always found some good wills who volunteered to fix GTK+ so that g-i worked again. I d like to thank Attilio Fiandrotti and Sven Neumann for their past work, but unfortunately it seems they have better things to do now. If someone takes over their work and hacks on GTK+ to get it to work correctly again on DirectFB, we will be able to go on this way at least for the squeeze release. This requires someone with serious DirectFB knowledge who will not be afraid to dig into the GDK internals. Option 2: switch to X11 If GTK+ doesn t work on DirectFB, there is another plan, but it needs to happen fast. It should be possible to make the installer work on X11. This has the advantage that we know X11 works fine and is maintained in the long term, and so does the X11 GTK+ backend. This has also the drawback to make the installation media slightly larger. This requires quite some work on udebs:

• Packaging of a number of libraries: at least libx11, libxi, libxext, libxrender, libxft, libdrm, libgcrypt, libpciaccess, libpixman, libxau, libxfont, libudev
• Maybe a few extras: libxcursor and dmz-cursor-theme (to have a nice cursor), libxrandr (to be able to select the installation resolution), libthai (for Thai language support)
• Packaging of the X server: xorg-server, xserver-xorg-video-fbdev
• Changes in the gtk+2.0 configure scripts so that other X11 extensions can be explicitly disabled
• Rework of udebs for cairo, pango1.0 and gtk+2.0 so that they are built against X11
• Rebuild the installer against the X11 GTK+ version
• Changes in the installer startup scripts: start the X server, configure the keyboard the X11 way, etc.

It looks like a lot, but there s nothing complicated in it. Anyone familiar enough with Debian can do this, with a little support from the maintainers of said packages. So this could well be you. Assuming you re interested in keeping g-i alive. Alternatives Other possibilities to support complex languages include:

• Use festival to ask questions and voice recognition software for the answers (we offer no guarantees for accidental wiping of your hard drive).
• Boot a live OS in a virtual machine and ask the user to run Google translation on the text (unfortunately we d need to ask in English).
• Render PNGs of all questions that could be asked and display them directly using DirectFB (requires migrating to Blu-ray by default for installation media).
• Port the installer to use the GTK+ Win32 port and pre-seed all the debconf questions before rebooting.
• Come on, be creative.

Bruce Everiss who is famous for being threatened with legal action by Evony has been writing about the supposed losses from game piracy, in his latest missive he copies the text from a number of blog comments without citing the original authors [1]. He copied my text without citing me as the author (which is at best shoddy journalism and by a fundamentalist attitude such as his could be considered as piracy). He also copied my text in with a bunch of other comments which he attributes to The thieves . It s unfortunate that Bruce doesn t seem capable of understanding irony, he wrote There is no doubt whatsoever that downloading and playing a game that should have been paid for is theft and then copied part of the text of my comment where I provided a dictionary definition of theft that directly contradicts his claim. If he was at all interested in quality writing he would cite his references and then when a dictionary is cited which disagrees with his opinion he would at least try to find a dictionary with a more agreeable definition. It shouldn t be THAT difficult to find a dictionary that has multiple definitions of theft of which one is agreeable to the MAFIAA [2]. Now if Bruce had properly read my comment he would have seen I ve started watching content from sites such as blip.tv (in the little time I have for such things) and I only play games that are part of the Debian distribution of Linux (free software) which makes it very clear to any reasonable interpretation that I am not a game pirate and probably not even a movie pirate. I did mention in a comment on Bruce s blog that the DVD experience of being forced to sit through a whinge about piracy was a factor that made buying a DVD a worse experience than downloading it, a concept that I expanded into a blog post on the relative technical merits of DVDs and pirate MP4 files [3]. That post received a number of interesting comments including one from Josselin Mouette which had some useful technical detail about subtitles and audio track storage. I had believed that there were some real technical advantages of DVDs but Josselin corrected me on this matter. Also one thing that is noteworthy is that Bruce seems to use a copyright picture in almost every post but he doesn t attribute any of them. It does seem unusual for someone to use commercial artwork without any copyright or trademark notices attached. This usually isn t a big deal for a blogger, a liberal interpretation of copyright and trademark law is usually expected in terms of blogging corporations will tend to be hesitant to invoke the Streisand effect by suing a blogger (EG Bruce blog came to fame when he was sued by Evony). But when a blogger is writing about the importance of not pirating anything it would seem sensible to go to the effort of citing trademark and copyright references and also mentioning the licence agreements under which the IP was used. I believe that any loss of customers and revenue by the MAFIAA and the gaming industry is due to the actions of the companies involved. They should just try to make their customers happy, otherwise they lose the customers. The same goes for bloggers. I read blogs written by people who disagree with me, and sometimes by people who offend me on occasion. But Bruce is making baseless claims while deliberately ignoring evidence. He is calling for strong anti-piracy measures while doing what could be considered as pirating my work. He uses words in ways that conflict with dictionary definitions, and he calls for an end to our current legal system by demanding punishment based on three accusations rather than any legal process. I even pointed out to Bruce that if there was a three strikes law regarding accusations of copyright infringement then his blog would be offline after three accusations by Evony. Sorry Bruce, if I was looking for irrational rants about copyright then I would look at what the members of the Science Fiction Writers of America (SFWA) are doing [4]. The SFWA people demonstrate as much knowledge of computers and the Internet as Bruce does, but they are at least really good writers. If it was just me unsubscribing from Bruce s RSS feed then it wouldn t matter (I m one of tens of thousands of readers). But I expect that a large portion of the new readers Bruce acquired after being attacked by Evony will disappear when they see Bruce as the attacker and everyone who uses the Internet as a potential victim of the Three Strikes law.

• [1] http://www.bruceongames.com/2010/01/22/what-game-thieves-have-to-say-for-themselves/
• [2] http://mafiaa.org/
• [3] http://etbe.coker.com.au/2010/01/06/which-is-better-original-dvd-or-pirate-mp4/
• [4] http://etbe.coker.com.au/2007/09/23/dmca-and-sci-fi/

This is it. We know the faces of people who will count in Europe during the 2009-2014 period. And we can count on them to make the EU weigh even less than it did until now. Jos Manuel Dur o Barroso, president of the European Commission. For 5 years, this ultra-liberal brought in his fanatic views of the free market, leading to unprecedented removals of regulations and legislations that could prevent large corporations to extort money from citizens. He holds a non-negligible responsibility on the (still unsolved) bank crisis of 2007. Yet, citizens voted en masse earlier this year for the EPP all across Europe, leading to his renewal. You get the commission you deserve. Herman Van Rompuy, president of the European Council. This is no secret that this transparent non-leader was the choice of Sarkozy after Tony Blair turned out to be an unsustainable choice. Yet, none of the 26 other members of the Council dared to raise a single finger against this choice. Sarkozy has completely lost his credit in France, but that doesn t prevent this council of cowards from trusting him, apparently. It s not as if there weren t good candidates, like Jean-Claude Juncker or Vaira V e-Freiberga. But having a competent, Europe-friendly president who actually knows his files and speaks many languages would have cast shadows on those who don t (see below). Catherine Ashton, foreign ministry of the EU. If there was any worse possible choice, I don t know which. This was the only position supposed to be affected to a socialist. And since the Labour party is still member of the PASD, despite their insane liberal economic policy and their full-scale paranoia leading to unprecedented freedom hunting in the UK, the position was given to someone from this party. And among them, they chose a person with a reputation of sloppiness and incompetence, who doesn t speak correctly a single foreign language. It is probable that, just like Van Rompuy s going to be Sarkozy s puppet, she s going to be the UK Foreign Office s servant. And we continentals all love the Foreign Office s policy, which is often in complete opposition to what the rest of Europe feels like. Jerzy Buzek, president of the European Parliament. You don t know him? Neither do I. A weak parliament goes with a weak parliament president. This way, the European Council has its hands free for behind-the-curtains arrangements, rather than letting the citizens representatives take action. Martin Schultz, president of the PASD group at the European Parliament. In order to ensure his place as president of the Parliament for the second half of the period, he betrayed his own people, and accepted any rotten compromise the EPP would propose for the key positions. Socialists have never been so weak in Brussels, and the total absence of leadership has something to do with it. Makes you proud to be European, heh? And of course you already know the real faces of Europe for the next years. Sarkozy, Merkel, Berlusconi, Brown. The main leaders from Western Europe, with their rotten governments who swore to slay any of the remaining personal freedoms in each of their countries. What a great image for EU in the world. What a great example to set. But again, you get the leaders you deserve. That s the whole point of democracy.

Since today for kfreebsd-amd64, and probably tomorrow for kfreebsd-i386 too, the gnome metapackage is installable on Debian GNU/kFreeBSD. In the end, this should hopefully give a fully functional desktop for these brand new architectures (to be included in the Squeeze release), with a few notable exceptions:

• no power management support (DeviceKit-Power needs porting);
• no roaming/wireless support (no support for libiw);
• no Bluetooth support (insufficient support in the FreeBSD kernel);
• no webcam support (no existing kernel API).

Apart from that, everything is supposed to work. So, if you want this to mean something, what we need now is some people to test the whole thing and find out if it actually does. Do you feel like helping? Install Debian GNU/kFreeBSD on your favorite virtual machine, upgrade it to the latest sid version, and apt-get install gnome. For everything that s not as enjoyable as it should be, report bugs.

Getting python2.6 as the default ASAP is currently the #1 priority for the Python modules team. I also consider it very important and tried to help with it, but it is starting to get depressing. The plan is to fix all packages in unstable to be compatible with python2.6 first. This would be easy if there hadn t been a very badly planned change in the installation paths that came together. Because of it, quite a number of packages have to be fixed. Two months ago, I filed a lot of bugs in that order. I missed a number of issues, but overall, almost all packages have been fixed, thanks to Kumar Appaiah, Bastian Venthur and everyone else who sent patches and NMUs. One of the biggest issues, though, comes from python-central. Since it doesn t handle some of the new paths that were introduced (which is somehow ironic, since the python-central maintainer, Matthias Klose, is also the python maintainer who did this change), a large number of packages FTBFS when built against python2.6. In Ubuntu, it turned out to be a giant mess, most packages using python-central needing changes, and we wanted to avoid that. This is why Piotr O arowski sent a NMU for python-central that fixes these issues for good. Guess what happened? Matthias Klose uploaded a new version that does not include the python2.6 fixes, completely discarding the work that has been done. And of course, making the upload of python2.6 to unstable, which was ready to be done in a few days, impossible. I think it s fine if Ubuntu maintainers don t have the time to handle their packages in Debian. But it is clearly not acceptable to hold back development in Debian, nor to treat it as a garbage dumpster where you can send all the crappy software solutions that were badly designed in Ubuntu to duplicate them in Debian. This is what Matthias has been doing for several years. For how long are we going to tolerate such behavior? For how long will we leave such a critical package in the hands of a single person with no interest in Debian?

Some time ago, I made an attempt at a gvfs package with disabled HAL support. The latest upstream version allows to use DeviceKit-Disks instead, through the gnome-disk-utility library. This change was supposed to bring a lot of improvement, among which:

• improved LUKS support;
• better management of permissions, using ConsoleKit and PolicyKit 1;
• simpler software stack, getting rid of gnome-mount.

Unfortunately, it turned out as a real fiasco, since there is no support for IDE CDs using ide_mod in DeviceKit-Disks. Upstream only uses libata, and Fedora has no requirements for compatibility with kernels shipped more than 2 months ago. The change had to be backed out. What you don t know yet is that Michael Biebl is awesome. Not only did he find some ways to comply with Bastian s requirements, but he implemented IDE CD support in DeviceKit. Which was not really easy. So, I d appreciate if some adventurous people could test the experimental gvfs packages in which there is still DeviceKit support. Please look for any regressions in them, especially with regard to removable media handling.

So, it s been 3 months since the last commit on GNote, and 1 month since it was officially abandoned. And nobody stepped up to maintain it. I can certainly understand why Hubert s motivation declined, GNote being a project to fight boredom , and all the innovation happening in tomboy. But if you remember all the fuss around Tomboy and GNote, thanks to Roy Schestowitz and his little minions, this is actually quite a tasty way for things to turn out. The utmost victory of the anti-Mono zealots was the decision from Fedora to include GNote by default and to drop Mono. Well done. I m still savoring my pop-corn.